The present disclosure, in some embodiments thereof, relates to state-dependent data forwarding and, more specifically, but not exclusively, to state-dependent data forwarding in a software-defined network.
OpenFlow is an emerging standard and protocol for creating software-defined networks (SDN). The OpenFlow protocol includes programmable forwarding elements that are characterized by their ability to be programmable by an external controller. The controller programs the OpenFlow Forwarding Element (FE), also called Forwarding Entity, by adding entries to forwarding tables whose structure is also defined by the OpenFlow protocol. The premise in OpenFlow and SDN is that the first frame of each new data flow is sent to the controller which in turn, after analyzing the frame headers, sends forwarding rules to all of the participating FEs. All of the subsequent frames of the same flow are handled by the OpenFlow FEs and are not sent to the controller, thus lowering the burden on controller resources.
However, the premise is broken if there is a need to monitor a state (or states) for a given data flow. The rules embodied in the OpenFlow table are stateless, meaning the forwarding decision per frame is dependent only on the information contained in the frame (e.g. values of its headers). Any decision that depends on a current or historical state must be sent to the controller, which therefore needs to handle many more packets than the original design called for.
Moreover, since in OpenFlow there are only stateless forwarding rules, there is no notion of a flow as a set of interrelated ingress and egress streams of traffic between participating hosts, i.e. when A is allowed to communicate with B then there are two rules, one for A→B(egress) and one for A←B(Ingress). In addition, there is no notion of a flow context for a flow, such as the port it came from, the virtual machine (VM) that sent it, etc.
In one solution, for any state-dependent operation on a data flow all of the frames related to the given flow are sent to the controller where either the controller or a related SDN application is used to process all of the frames. Thus instead of efficient operation at the FE level, which is optimized for packet processing both in term of location and in terms of adaptation, frames need to be delivered to a remote point with all of the inefficacies resulting from the delivery.
Furthermore, there are major use cases for which there is no solution in OpenFlow whatsoever, not even by sending data frames to controller, as they are based on a frame by frame decision. Examples include:                1) State-dependent firewall;        2) Link Aggregation (LAG);        3) Operation, Administration, and Management (OAM) (for example 802.3 ah link OAM);        4) APS (Automatic Protection Switching);        5) Load balancing; and        6) Bandwidth (BW) capping.        
There is currently no efficient SDN solution for data forwarding in cases in which data forwarding is based on a frame by frame decision.
In some cases external components are added to the OpenFlow switch, for example IP tables for a firewall, port group for LAG. However these solutions are tailored for a specific use case, are not connected to the SDN framework. This results in non-optimal resource utilization due to redundant functionality on the switch and external components. Additionally, such solutions are not relevant for hardware-based OpenFlow switches.
Other solutions add the full functionality of state-dependent applications to the FE (for example a firewall SDN application). This approach is wasteful because all frames need to be sent to the SDN controller and back to the FE, thus limiting the scale of the SDN controller as it needs to track a large number of data flows.
Additional background art includes:
Open Networking Foundation OpenFlow Switch Specification; and
Intel® Architecture Processors White Paper on “Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence”.